home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 098 / cstd.arc / CSTD7#3 < prev    next >
Encoding:
Text File  |  1985-07-28  |  7.1 KB  |  181 lines
  1. /* ---------- "mod.std.c Digest V7#3" ---------- */
  2. From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
  3.  
  4.  
  5. mod.std.c Digest            Mon, 24 Jun 85       Volume 7 : Issue   3 
  6.  
  7. Today's Topics:
  8.                  Section B.2.4.1 Translation limits 
  9.                       Section C.1.2 Identifiers
  10.                  Section C.3.15 Conditional operator
  11.                    Section C.4 Constant Expressions
  12.                  Section C.5.3.3 Function declarators
  13.                  Section C.8.1 Source file inclusion
  14.                  Section C.8.3 Conditional inclusion
  15.                  Section D.9.7.11 The ungetc function
  16. ----------------------------------------------------------------------
  17.  
  18. Date: Thu, 20 Jun 85 20:58 EDT
  19. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  20. Subject: Section B.2.4.1 Translation limits 
  21. To: cbosgd!std-c@BERKELEY
  22.  
  23. Ref. Doc.: X3J11/85-045
  24.  
  25. Comments on preliminary draft proposed ANSI C, dated April 30, 1985
  26.  
  27.           In general, I think the standard is pretty well done.  There
  28. are a few picky details that bothered me, tho.  I've tried to avoid
  29. mentioning things that have been hashed to death already, but one or two
  30. of my comments may repeat things others have said.
  31.  
  32. Section B.2.4.1 Translation limits 
  33. >          The implementation must be able to compile at least one
  34. >program that or exceeds all of the following translation limits:
  35. Is that really what you mean?  Shouldn't it be something like:
  36.           The implementation must be able to compile all legal programs
  37. which do not exceed the following translation limits:
  38.  
  39. >* maximum number of alphabetic cases in an external identifier (1)
  40. after the above line, may I suggest adding:
  41. * maximum number of alphabetic cases in an internal identifier or macro name(2)
  42.  
  43. >* maximum length of input program logical source lines (509)
  44. Why 509?  Seems like a rather strange number.
  45.  
  46.           Also, I would like to see a "note" here to the effect that if
  47. an implementation can provide larger numbers for any of these, that's
  48. great, and in particular encouraging implementors to provide two case/
  49. thirty-one character external identifiers if possible. 
  50.  
  51. ------------------------------
  52.  
  53. Date: Thu, 20 Jun 85 20:58 EDT
  54. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  55. Subject: Section C.1.2 Identifiers
  56. To: cbosgd!std-c@BERKELEY
  57.  
  58. Section C.1.2 Identifiers
  59.  
  60. Constraints In a "note" in section D.1.3, it is mentioned that 
  61. > As stated previously, external identifiers beginning with underscore 
  62. > are reserved.  
  63. I couldn't find the previous reference.  It should be mentioned in this
  64. section (C.1.2), or a forward reference given.  Also, I understood that
  65. all identifiers starting with two underscores ("__", as in __LINE__)
  66. were reserved as well, but I can't find that, either.
  67.  
  68. Re: my previous message (above)
  69.  
  70. I've found where it talks about reserving external identifiers starting
  71. with _ and all identifiers starting with __.  (section D.1.2)  I still
  72. think there should be a forward reference in section C.1.2.
  73.  
  74. ------------------------------
  75.  
  76. Date: Thu, 20 Jun 85 20:58 EDT
  77. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  78. Subject: Section C.3.15 Conditional operator
  79. To: cbosgd!std-c@BERKELEY
  80.  
  81. Section C.3.15 Conditional operator
  82.  
  83. >Syntax
  84. > conditional-expression:
  85. >     logical-OR-expression
  86. >     logical-OR-expression ? logical-OR-expression : conditional-expression
  87. This allows a?b:c?d:e but not a?b?c:d:e, which seems strange, especially
  88. as I prefer the second.  (The first could be read as (a?b:c)?d:e, but
  89. the second is unambiguous).  I suggest changing the last line to
  90.       logical-OR-expression ? conditional-expression : conditional-expression
  91.  
  92. ------------------------------
  93.  
  94. Date: Thu, 20 Jun 85 20:58 EDT
  95. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  96. Subject: Section C.4 Constant Expressions
  97. To: cbosgd!std-c@BERKELEY
  98.  
  99. Section C.4 Constant Expressions
  100. Constraints
  101.  
  102. Aw, gee, the language of this section makes "a"[0] not an "integral
  103. constant expression" (as used in case statements), because it disallows
  104. array-subscripting ([]) in them.  How about allowing array-subscripting
  105. iff the array in question is "array of constant <type>" and the
  106. subscript is constant?  (I'll bet there are real uses for this, not just
  107. my stupid CTRL(X) macro.)  You should also allow (equivalently) *pointer
  108. iff pointer is a constant pointer to constant <type> (since that's just
  109. pointer[0]).  One could also make a case for allowing . and -> iff the
  110. appropriate things are constant.
  111.  
  112. ------------------------------
  113.  
  114. Date: Thu, 20 Jun 85 20:58 EDT
  115. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  116. Subject: Section C.5.3.3 Function declarators
  117. To: cbosgd!std-c@BERKELEY
  118.  
  119. Section C.5.3.3 Function declarators
  120.  
  121. It would be nice if in a non-definition declaration for a function,
  122. f(...) was allowed, meaning no information given (just like f() now.)
  123. (This is the usage in C++.) Also, in function definitions, it would be
  124. neat if you could say f(void) { /*...*/ }, meaning no arguments
  125. (currently f() { /*...*/ }).  (This would mean that you could always add
  126. on a function definition to a function declaration lacking one.)
  127.  
  128. ------------------------------
  129.  
  130. Date: Thu, 20 Jun 85 20:58 EDT
  131. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  132. Subject: Section C.8.1 Source file inclusion
  133. To: cbosgd!std-c@BERKELEY
  134.  
  135. Section C.8.1 Source file inclusion
  136. Constraints
  137.  
  138. In a # include <file> new-line, '>' may not appear in "file." This is
  139. bad news because many file systems use '>' in their file names.  (e.g.,
  140. MULTICS, whatever RUTGERS.ARPA runs, VMS allows it in place of ], etc.)
  141. Furthermore, its not necessary, since the final '>' can be identified by
  142. the fact that there is only (possibly) white-space and a new-line
  143. following it.  I.e., 
  144. #include <sys>stuff.h>  /* even if there's a comment */
  145. is strange looking, but unambiguous.  The constraint should be omitted,
  146. or, at worse, allow '\>' for '>'.
  147.  
  148. ------------------------------
  149.  
  150. Date: Thu, 20 Jun 85 20:58 EDT
  151. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  152. Subject: Section C.8.3 Conditional inclusion
  153. To: cbosgd!std-c@BERKELEY
  154.  
  155. Section C.8.3 Conditional inclusion
  156.  
  157. "elif" is an extremely ugly name.  Furthermore, one can't replace it (like
  158. on can other ugly names like "const") with the preprocessor since it's a
  159. preprocessor thing.  Please replace it with "elseif", which is clearer,
  160. and looks more like "endif".
  161.  
  162. ------------------------------
  163.  
  164. Date: Thu, 20 Jun 85 20:58 EDT
  165. From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
  166. Subject: Section D.9.7.11 The ungetc function
  167. To: cbosgd!std-c@BERKELEY
  168.  
  169. Section D.9.7.11 The ungetc function
  170.  
  171. How about a limit macro, UNGETC_PUSHBACK_LIMIT, indicating how many
  172. characters one is guaranteed to be able to push back.  (It would have to
  173. be at least 1., of course.)  Also, some versions of ungetc (or similar)
  174. only allow one to pushback the last character(s) read.  The standard
  175. should clearly state that any character can be pushed back.
  176.  
  177. ------------------------------
  178.  
  179. End of mod.std.c Digest - Mon, 24 Jun 85 17:48:37 EDT
  180. ******************************
  181.